-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Add case custom status feature #33579
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Preview links (active after the
|
janine-c
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastico! I have some small suggestions, but nothing showstoppy at all :)
| 1. Navigate to [**Settings > Shared Settings > Case Types**][2]. | ||
| 2. Select the case type you want to update. | ||
| 3. Scroll to the **Statuses** section. | ||
| 4. Add a new status under one of the three existing status groups: **Open, In-Progress,** or **Closed**. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 4. Add a new status under one of the three existing status groups: **Open, In-Progress,** or **Closed**. | |
| 4. Add a new status under one of the three existing status groups: **Open, In Progress,** or **Closed**. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the hyphen in the UI, and it's not a compound adjective, so I think this is okay?
| 2. Select the case type you want to update. | ||
| 3. Scroll to the **Statuses** section. | ||
| 4. Add a new status under one of the three existing status groups: **Open, In-Progress,** or **Closed**. | ||
| 5. (Optional) Set a new **default status** for each status group. Default Statuses are used in automations as the preferred statuses for the group when exact status names are not provided. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 5. (Optional) Set a new **default status** for each status group. Default Statuses are used in automations as the preferred statuses for the group when exact status names are not provided. | |
| 5. (Optional) Set a new **default status** for each status group. Default statuses are used in automations as the preferred statuses for the group when exact status names are not provided. |
|
|
||
| <!-- \[Screenshot here\] --> | ||
|
|
||
| * Each status group (Open, In-Progress, Closed) must contain at least one status. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| * Each status group (Open, In-Progress, Closed) must contain at least one status. | |
| * Each status group (Open, In Progress, Closed) must contain at least one status. |
| * Each status group (Open, In-Progress, Closed) must contain at least one status. | ||
| * You can delete an existing status, but you must first migrate any cases currently using that status to another status in the same group. | ||
| * Custom statuses behave exactly the same as Datadog's built-in statuses. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These bullets are all good information, but I think they could use a little structural signposting to indicate what the bulleted list actually is. (I tried to think of an analogy, and maybe it's like if you opened an old recipe book and a sticky note fell out that said "temperature actually needs to be 375 degrees or else the muffins will explode." And you're like, this is good and likely correct information, but when do I apply it??)
Because it's more general information that doesn't directly pertain to creating custom statuses, I don't think it should be under the "Create a custom status" heading. Somewhere in the intro would work, and/or you could create an "Understand how custom statuses behave" header or something similar. That way, users will have a clearer idea of what the bulleted list is going to contain before they've even started reading it 🙂
| Case Management supports customizable case statuses. By default, cases move through Open, In Progress, and Closed. You can add additional statuses to represent reviews, handoffs, or other workflow steps. | ||
|
|
||
| Custom statuses help you: | ||
| - Standardize how work moves through each stage of a case lifecycle. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| - Standardize how work moves through each stage of a case lifecycle. | |
| - Standardize how work moves through each stage of a case life cycle. |
Thank you Vale!
What does this PR do? What is the motivation?
Merge instructions
Merge readiness:
Warning
Pending product GA